יש לי טבלה בשם tutorials שמכילה מדריכים עם העמודות:
id, title, author, time, description, content, tags, views, part
העמודה content היא מסוג text והיא יכולה להכיל מקסימום 65535 תווים.
במקרה והמשתמש יוצר מדריך חדש עם יותר מ-65535 אני מחלק את ה-content לחלקים של 65535 תווים מקסימום לכל חלק עם str_split ומכניס למסד בצורה הבאה:
החלק הראשון נכנס כרגיל, עם כל שאר הפרטים והעמודה part שווה 0. החלק השני נכנס כשורה חדשה רק עם אותו title, author ו-time ועם part שווה 1 וככה כל שאר החלקים כש-part כל פעם עולה ב-1.
הבעיה היא בשליפה. אני יכול לשלוף את המדריכים שאני רוצה ואז עם php לחבר את ה-contentים, אבל אני לא רוצה ככה.
אני רוצה לשלוף את כל המדריכים מהטבלה. כל מדריך יהיה שורה בתוצאות, עם ה-content אחרי שכבר כל החלקים מחוברים.
אני יודע שצריך להשתמש במשתנה ולצבור בו את התוכן. אבל לא עולה לי רעיון איך לעשות את זה.
*החלקים השונים של המדריך הם לא בהכרח שורות רצופות זו אחר זו.
יש הצעות?
תודה רבה מראש.
16 תשובות
ענה
אולי בpart תכניס את ה ID של המדריר הראשון.
וככה תבדוק עם יש עוד מדריכים אם אותו ID ואז תחבר בניהם
ענה
iiddaannyy
ב
20 ליוני 2012
#
זה לא עוזר לי. אני יודע איזה חלק שייך לאיזה מדריך, לכן נתתי להם את אותו ה-time, author ו-title.
-----------------------------
לא שורות רצופות.
אם מישהו יפרסם מדריך עם פחות מ-65535 תהיה רק שורה אחת. ונניח שאחר כך מישהו אחר הכניס מדריך אחר.
ואז המשתמש הראשון עורך את המדריך שלו ומוסיף עוד תווים, וזה הופך להיות גדול מ-65535. במקרה כזה תתווסף שורה נוספת עם אותו ה-title, author ו-time עם part ששווה 1, אחרי השורה של המדריך של המשתמש השני.
ענה
iiddaannyy
ב
20 ליוני 2012
#
רק הראיתי לך דוגמה של מצב בו החלקים הם לא צמודים. אבל זה שטויות, עם ORDER BY אני שולף אותם צמודים.
השאלה היא איך לחבר את ה-content בשליפה ולשלוף את זה כבר מחובר.
ענה
למה לא לשנות ל longtext ואת החלוקה לעשות בעת התצוגה ?
אם יש יותר מ 65k לחתוך את הטקסט ולהציג קישור לחלק שתיים
ענה
iiddaannyy
ב
20 ליוני 2012
#
לא הבנת. אין "חלק שתיים".
המדריך מוצג בשלמותו. גם אם הכניסו יותר מ-65535 תווים, רק במסד הוא מחולק, למשתמש אני מציג את המדריך בשלמותו.
חשבתי אתה עושה את כל זה בשביל להציג את המדריך בנפרד.
אז למה בכלל לעשות את החלוקה במסד ? שים longtext וזהו
ענה
iiddaannyy
ב
20 ליוני 2012
#
אם כבר אז mediumtext.
ואני עושה את זה כי 90% ואפילו יותר מהמדריכים הם מתחת ל-65535 תווים. הדבר הזה רק למקרים מיוחדים.
ובסוף פתרתי את זה אחרי איזו שינה טובה חח :)
זה לא שכל שורה עכשיו תתפוס לך 4 גיג'ה בזיכרון.
longtext רק אומר שהשדה הזה יכול להכיל עד 4 גיג'ה
ואין שום סיבה שבעולם לכתוב קוד מעווט שמחלק את זה לשני שורות בזמן השמירה. זה בטוח טופס הרבה יותר מקום ועובד הרבה יותר לאט.
ענה
iiddaannyy
ב
20 ליוני 2012
#
אם כך, מה הטעם להשתמש בשדות קטנים יותר בכלל?
שדות קטנים זה tinytext ו varchar255 שהם טיפה יותר מהירים.
כל שאר משפחת הטקסט הם בגדר אותה מהירות וגודל.
ענה
iiddaannyy
ב
20 ליוני 2012
#
@razand
לפי ההודעה של אלכס זה לא ככה.
@intval
אם כך, מה הטעם להשתמש בכלל בשדה כמו text?
text יכול לשמור עד 65k, לאומתו longtext יכול 4g
למרות ששניהם יכולים להתאים יופי לשמירת טקסט באורך 3000 תווים, שזה סדר גודל פוסט,
longtext מקצה לעצמו 4 בייטים בנוסף מעבר לאורך המחרוזת ששמרת
mediumtext עוד 3 בייטים
text עוד שני בייטים
tinytext / varchar עוד בייט אחד מעבר לכמות הנתונים ששמורה בהם.
זה אומר שאם יש לך נניח מליון פוסטים באתר, שימוש ב mediumtext יחסוך לך 1 מליון בייט לאומת longtext שזה שווה ערך למגהבייט אחד.
אבל אם יש לך 500 מליון שורות ובמקום tinytext שמת longtext
אז הפסדת גיג'ה וחצי
ענה
iiddaannyy
ב
20 ליוני 2012
#
זה כל ההבדל? בייט?
תודה רבה. :)
בחרתי ב-mediumtext. אין טעם ל-logtext גם אם ההבדל מינורי. :)